Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review. Walkthrough
ChangesMapped control state evaluation
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~3 minutes Change: Bug fix Suggested reviewers: Merge Risk: ⚪ Minimal · up to The dynamic type evaluation now supplies the expected row state and dependency values, with inspected consumers matching that contract. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…row fields When a schema field uses a dynamic type function (type as a function) and is rendered inside a collection (e.g., chain tasks), the function always received the top-level schema data instead of the row-level data. This caused the field to fall through to its default type, ignoring the actual field values in the row. Pass the parent-path state to the dynamic type function so it receives the correct context for collection row fields.
8cf4ded to
7e5d3ef
Compare
…row fields (#10398) When a schema field uses a dynamic type function (type as a function) and is rendered inside a collection (e.g. chain tasks), the function always received the top-level schema data instead of the row-level data. This caused the field to fall through to its default type, ignoring the actual field values in the row. Resolve the type callback's state against the field's own container instead, mirroring what cell() already gets via its row argument: for a field inside a collection row that is the row, and for a top-level field the parent path is empty, so the whole schema data comes back as before. Nested tabs and fieldsets carry no id, so they do not extend the access path and are unaffected. As well as the pg_timetable case that prompted this, it repairs the expanded-row Definition forms that were already relying on row state and silently getting the table's: the foreign key 'Referencing' column list, the partition name control's attach/create switch, and the column dialog's identity/generated constraint options.
|
Thanks Regina, this is a good catch, and it fixes rather more than the pg_timetable case that prompted it. I traced the access paths before merging: nested tabs and fieldsets carry no Worth noting for the archaeology: as well as your case, this repairs the expanded-row forms that were already relying on row state and silently getting the table's, namely the foreign key 'Referencing' column list, the partition name attach/create switch, and the column dialog's identity/generated options. Merged to master as 6312baa. Since the squash changes the SHA, GitHub won't close this automatically, so I'm closing it by hand. |
2 participants
…row fields
When a schema field uses a dynamic type function (type as a function) and is rendered inside a collection (e.g., chain tasks), the function always received the top-level schema data instead of the row-level data. This caused the field to fall through to its default type, ignoring the actual field values in the row.
Pass the parent-path state to the dynamic type function so it receives the correct context for collection row fields.
I ran into this issue when building pg_timetable UI - #10152 that when building a new Chain and Tasks in one step, the Kind toggle didn't change options based on Kind. This patch fixes it, but didn't seem appropriate to put in as part of pg_timetable since it's a global issue. I don't think any existing elements are impacted by it yet.
Summary by CodeRabbit